FIG. 1 is a schematic diagram illustrating some of the components in a “traditional” (i.e. non-SDN architecture) network. In this example, a first node 100 of a type “A” is arranged to communicate with a plurality of user terminals (by way of example, four such user terminals are shown, as UE1 to UE4) by any suitable means, e.g. via an IP backbone Core Network (CN) 200 that includes a Serving GPRS Support Node (SGSN). In this example, the first node 100 is statically connected to a second node 300 of a type “B” by a network 400 comprising one or more appropriately configured forwarding elements (e.g. routers and switches), or by physically connecting the first and second nodes, e.g. via point-to-point links. By way of example, the first node 100 is provided in the form of a Gateway such as a Packet Data Network Gateway (PDN-GW) or a Gateway GPRS Support Node (GGSN), which may, as in the present example, include a Policy and Charging Enforcement Function (PCEF). The second node 300 may, as in the present example, be provided in the form of a value-added service (VAS) node configured to provide a value-added service in the form of content filtering, which requires application service detection based on Deep Packet Inspection (DPI) of received user data packets. The second node 300 may alternatively or additionally provide another kind of VAS, such as HTTP Header Enrichment. Regardless of the type of VAS being applied, DPI technology is used to classify IP packets according to a configured tree of rules, assigning classified IP packets to one or more associated service sessions. As is well-known, Shallow Packet Inspection (SPI) refers to packet inspection up to OSI Layer 3 or OSI Layer 4, whereas DPI refers to packet inspection beyond the level of SPI, from OSI Layer 4 or 5 up to OSI layer 7. DPI has been standardized in 3GPP Rel11, in the so-called Traffic Detection Function (TDF), which refers to a stand-alone node. However, DPI functionality may, as in the present example, run collocated with PCEF.
To provide the value-added service to one of the user terminals UE1 to UE4, the first and second nodes 100 and 300 need to exchange between them user data packets conveying user data plane information (e.g. samples of a VoIP call, multimedia information, HTTP Requests and responses etc.) as well as control data packets conveying control signalling for managing the processing of data packet flows carrying the user data plane information. The control data packets may, for example, be exchanged using the RADIUS protocol, for purposes such as identification, authentication, authorization etc. In the present example, the RADIUS signaling is used by the second node 300 to retrieve relevant subscriber session parameters (e.g. a subscriber identifier such as IMSI, MSISDN, or another parameter such as the UE's location, etc.), specifically to identify the user or other relevant parameter and apply the corresponding content filtering functionality.
As the first and second nodes 100 and 300 are statically connected to each other by the network 400, all data packets (each being either a user data packet or a control data packet) will be forwarded from the first node 100 to the second node 300. This is illustrated in FIG. 1, where there are four different user sessions (relating to UE1, UE2, UE3 and UE4) and where RADIUS messages (R1, R2, R3 and R4) and user data traffic (D1, D2, D3 and D4) are all routed to the second node 300.
Software Defined Networking (SDN) is an emerging network architecture which addresses a shortcoming of the static architecture of conventional networks, namely that it is ill-suited to the dynamic traffic steering needs of today's packet backbone networks. SDN decouples the network control and forwarding functions, and logically centralizes network intelligence and state. This enables network control to be directly programmable, and the underlying infrastructure to be abstracted for applications and network services. In SDN, the control plane logic is handled by a logically centralised server (the so-called “SDN controller”), and the forwarding plane consists of simplified forwarding elements (so-called “OpenFlow Switches” (OFS) in the context of the OpenFlow protocol) that are programmed by the SDN controller.
Thus, in contrast to the “traditional” network architecture outlined above, SDN architectures provide the advantage of allowing the routing of information between the nodes to be configured, changed or otherwise managed in a dynamic and easy manner, by allowing the forwarding elements in the network to be dynamically and easily configured and adjusted. This SDN feature, in turn, provides the advantage (among others) of making it possible to modify the number of nodes of a certain type (e.g. increasing/decreasing the number of nodes of type “B” in the above example, according to dynamic criteria, such as usage of a certain service, availability/unavailability of certain control features, etc.) in an dynamic and easy manner.
One application of SDN is the dynamic service chaining of value-added-functions. In SDN, service chaining is a concept that refers to the forwarding of traffic of specific traffic types along a predefined set of service functions (VAS) called a “service chain”. This implies that when a data packet enters the SDN domain, it has to be classified and, once classified, it can be forwarded to the next service function or to the gateway at the end of a service chain.
As per 3GPP 29.061, SGi is the reference point between the PDN-GW and the packet data network. The packet data network may be an operator external public or private packet data network or an intra-operator packet data network, e.g. for provision of IMS services. This reference point corresponds to Gi for 3GPP accesses.